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Using GOST Ciphers in the Encapsulating Security 
Payload (ESP) and Internet Key Exchange Version 2 
(IKEv2) Protocols 


Abstract 


This document defines a set of encryption transforms for use in the Encapsulating Security 
Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of 
the IP Security (IPsec) protocol suite. The transforms are based on the GOST R 34.12-2015 block 
ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and 
the external rekeying approach. 


This specification was developed to facilitate implementations that wish to support the GOST 
algorithms. This document does not imply IETF endorsement of the cryptographic algorithms 
used in this document. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9227. 
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Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
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1. Introduction 


The IP Security (IPsec) protocol suite consists of several protocols, of which the Encapsulating 
Security Payload (ESP) [RFC4303] and the Internet Key Exchange version 2 (IKEv2) [RFC7296] are 
most widely used. This document defines four transforms for ESP and IKEv2 based on Russian 
cryptographic standard algorithms (often referred to as "GOST" algorithms). These definitions are 
based on the recommendations [GOST-ESP] established by the Federal Agency on Technical 
Regulating and Metrology (Rosstandart), which describe how Russian cryptographic standard 
algorithms are used in ESP and IKEv2. The transforms defined in this document are based on two 
block ciphers from Russian cryptographic standard algorithms -- "Kuznyechik" [GOST3412-2015] 
[RFC7801] and "Magma" [GOST3412-2015] [RFC8891] in Multilinear Galois Mode (MGM) [GOST- 
MGM] [RFC9058]. These transforms provide Authenticated Encryption with Associated Data 
(AEAD). An external rekeying mechanism, described in [RFC8645], is also used in these transforms 
to limit the load on session keys. 


Because the GOST specification includes the definition of both 128-bit ("Kuznyechik") and 64-bit 
("Magma") block ciphers, both are included in this document. Implementers should make 
themselves aware of the relative security and other cost-benefit implications of the two ciphers. 
See Section 5 for more details. 


This specification was developed to facilitate implementations that wish to support the GOST 
algorithms. This document does not imply IETF endorsement of the cryptographic algorithms 
used in this document. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. Overview 


Russian cryptographic standard algorithms, often referred to as "GOST" algorithms, constitute a 
set of cryptographic algorithms of different types -- ciphers, hash functions, digital signatures, etc. 
In particular, Russian cryptographic standard [GOST3412-2015] defines two block ciphers — 
"Kuznyechik" (also defined in [RFC7801]) and "Magma" (also defined in [RFC8891]). Both ciphers 
use a 256-bit key. "Kuznyechik" has a block size of 128 bits, while "Magma" has a 64-bit block. 


Multilinear Galois Mode (MGM) is an AEAD mode defined in [GOST-MGM] and [RFC9058]. It is 
claimed to provide defense against some attacks on well-known AEAD modes, like Galois/Counter 
Mode (GCM). 
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[RFC8645] defines mechanisms that can be used to limit the number of times any particular 
session key is used. One of these mechanisms, called external rekeying with tree-based 
construction (defined in Section 5.2.3 of [RFC8645]), is used in the defined transforms. For the 
purpose of deriving subordinate keys, the Key Derivation Function (KDF) 

KDF GOSTR3411 2012 256, defined in Section 4.5 of [RFC7836], is used. This KDF is based on a 
Hashed Message Authentication Code (HMAC) construction [RFC2104] with a Russian GOST hash 
function defined in Russian cryptographic standard [GOST3411-2012] (also defined in [RFC6986]). 


4. Description of Transforms 


This document defines four transforms of Type 1 (Encryption Algorithm) for use in ESP and 
IKEv2. All of them use MGM as the mode of operation with tree-based external rekeying. The 
transforms differ in underlying ciphers and in cryptographic services they provide. 


e ENCR KUZNYECHIK MGM KTREE (Transform ID 32) is an AEAD transform based on the 
"Kuznyechik" algorithm; it provides confidentiality and message authentication and thus can 
be used in both ESP and IKEv2. 


* ENCR MAGMA MGM KTREE (Transform ID 33) is an AEAD transform based on the "Magma" 
algorithm; it provides confidentiality and message authentication and thus can be used in 
both ESP and IKEv2. 


* ENCR KUZNYECHIK MGM MAC KTREE (Transform ID 34) is a MAC-only transform based on 
the "Kuznyechik" algorithm; it provides no confidentiality and thus can only be used in ESP, 
but not in IKEv2. 

* ENCR MAGMA MGM MAC KTREE (Transform ID 35) is a MAC-only transform based on the 
"Magma" algorithm; it provides no confidentiality and thus can only be used in ESP, but not in 
IKEv2. 


Note that transforms ENCR KUZNYECHIK MGM MAC KTREE and 

ENCR MAGMA MGM MAC KTREE don't provide any confidentiality, but they are defined as Type 
1 (Encryption Algorithm) transforms because of the need to include an Initialization Vector (IV), 
which is impossible for Type 3 (Integrity Algorithm) transforms. 


4.1. Tree-Based External Rekeying 


All four transforms use the same tree-based external rekeying mechanism. The idea is that the 
key that is provided for the transform is not directly used to protect messages. Instead, a tree of 
keys is derived using this key as a root. This tree may have several levels. The leaf keys are used 
for message protection, while intermediate-node keys are used to derive lower-level keys, 
including leaf keys. See Section 5.2.3 of [RFC8645] for more details. This construction allows us to 
protect a large amount of data, at the same time providing a bound on a number of times any 
particular key in the tree is used, thus defending against some side-channel attacks and also 
increasing the key lifetime limitations based on combinatorial properties. 


The transforms defined in this document use a three-level tree. The leaf key that protects a 
message is computed as follows: 
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K_msg = KDF (KDF (KDF (K, 11, 0x00 | i1), 12, i2), 13, i3) 
where: 


KDF (k,1, s) Key Derivation Function KDF GOSTR3411 2012 256 (defined in Section 4.5 of 
[RFC7836], which accepts three input parameters — a key (k), a label (D, and a 
seed (s) - and provides a new key as output 


K the root key for the tree (see Section 4.4) 
11,12,13 labels defined as 6-octet ASCII strings without null termination: 
]- "level" 
12= "level2" 
13= "level3" 
11,12,13 parameters that determine which keys out of the tree are used on each level. 


Together, they determine a leaf key that is used for message protection; the 
length of i1 is one octet, and i2 and i3 are two-octet integers in network byte 
order 


| indicates concatenation 


This construction allows us to generate up to 28 keys on level1 and up to 216 keys on levels 2and 
3. So, the total number of possible leaf keys generated from a single Security Association (SA) key 


is 220. 


This specification doesn't impose any requirements on how frequently external rekeying takes 
place. It is expected that the sending application will follow its own policy dictating how many 
times the keys on each level must be used. 


4.2. Initialization Vector Format 


Each message protected by the defined transforms MUST contain an IV. The IV has a size of 64 bits 
and consists of four fields. The fields i1, 12, and i3 are parameters that determine the particular 
leaf key this message was protected with (see Section 4.1). The fourth field is a counter, 
representing the message number for this key. 


1 2 3 
0518243245550 sy) peso 7s ee 2 ve SKINNI 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| il | i2 | i3 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| i3 (cont) | pnum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: IV Format 
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where: 


i1 (1 octet), i2 (2 octets), i3 (2 octets): parameters that determine the particular key used to 
protect this message; 2-octet parameters are integers in network byte order 


pnum (3 octets): message counter in network byte order for the leaf key protecting this 


224 


message; up to messages may be protected using a single leaf key 


For any given SA, the IV MUST NOT be used more than once, but there is no requirement that IV be 
unpredictable. 


4.3. Nonce Format for MGM 


MGM requires a per-message nonce (called the Initial Counter Nonce, or ICN in [RFC9058]) that 
MUST be unique in the context of any leaf key. The size of the ICN is n-1 bits, where n is the block 
size of the underlying cipher. The two ciphers used in the transforms defined in this document 
have different block sizes, so two different formats for the ICN are defined. 


MGM specification requires that the nonce be n-1 bits in size, where n is the block size of the 
underlying cipher. This document defines MGM nonces having n bits (the block size of the 
underlying cipher) in size. Since n is always a multiple of 8 bits, this makes MGM nonces having a 
whole number of octets. When used inside MGM, the most significant bit of the first octet of the 
nonce (represented as an octet string) is dropped, making the effective size of the nonce equal to 
n-1 bits. Note that the dropped bit is a part of the "zero" field (see Figures 2 and 3), which is always 
set to 0, so no information is lost when it is dropped. 


4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher 


For transforms based on the "Kuznyechik" cipher (ENCR KUZNYECHIK MGM KTREE and 
ENCR KUZNYECHIK MGM MAC KTREE), the ICN consists of a "zero" octet; a 24-bit message 
counter; and a 96-bit secret salt, which is fixed for the SA and is not transmitted. 


1 2 3 
05182132455 1605728502051098210324:55986:57285900510205 3245596087 8802 881 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| zero | pnum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
salt 


| | 

| | 

| | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 2: Nonce Format for Transforms Based on the "Kuznyechik" Cipher 


where: 


zero(10ctet) setto 0 
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pnum (3 octets): the counter for the messages protected by the given leaf key; this field MUST be 
equal to the pnum field in the IV 


salt (12 octets): secret salt. The salt is a string of bits that are formed when the SA is created (see 
Section 44 for details). The salt does not change during the SA's lifetime and is not transmitted 
on the wire. Every SA will have its own salt. 


4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher 


For transforms based on the "Magma" cipher (ENCR MAGMA MGM KTREE and 
ENCR MAGMA MGM MAC KTREE), the ICN consists of a "zero" octet; a 24-bit message counter; 
and a 32-bit secret salt, which is fixed for the SA and is not transmitted. 


1 2 3 
A I A A 878 9:0 £0 Xl 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| zero | pnum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| salt 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 3: Nonce Format for Transforms Based on the "Magma" Cipher 


+—+—+ 


where: 


zero (1 octet): setto0 


pnum (3 octets): the counter for the messages protected by the given leaf key; this field MUST be 
equal to the pnum field in the IV 


salt (4octets): secret salt. The salt is a string of bits that are formed when the SA is created (see 
Section 44 for details). The salt does not change during the SA's lifetime and is not transmitted 
on the wire. Every SA will have its own salt. 


4.4. Keying Material 


We'll call a string of bits that is used to initialize the transforms defined in this specification a 
"transform key". The transform key is a composite entity consisting of the root key for the tree 
and the secret salt. 


The transform key for the ENCR KUZNYECHIK MGM KTREE and 

ENCR KUZNYECHIK MGM MAC KTREE transforms consists of 352 bits (44 octets), of which the 
first 256 bits is a root key for the tree (denoted as K in Section 4.1) and the remaining 96 bits is a 
secret salt (see Section 4.3.1). 


The transform key for the ENCR MAGMA MGM KTREE and ENCR MAGMA MGM MAC KTREE 
transforms consists of 288 bits (36 octets), of which the first 256 bits is a root key for the tree 
(denoted as Kin Section 4.1) and the remaining 32 bits is a secret salt (see Section 4.3.2). 
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In the case of ESP, the transform keys are extracted from the KEYMAT as defined in Section 2.17 of 
[RFC7296]. In the case of IKEv2, the transform keys are either SK ei orSK er, which are generated 
as defined in Section 2.14 of [RFC7296]. Note that since these transforms provide authenticated 
encryption, no additional keys are needed for authentication. This means that, in the case of 
IKEv2, the keys SK ai/SK ar are not used and MUST be treated as having zero length. 


4.5. Integrity Check Value 


The length of the authentication tag that MGM can compute is in the range from 32 bits to the 
block size of the underlying cipher. Section 4 of [RFC9058] states that the authentication tag 
length MUST be fixed for a particular protocol. For transforms based on the "Kuznyechik" cipher 
(ENCR KUZNYECHIK MGM KTREE and ENCR KUZNYECHIK MGM MAC KTREE), the resulting 
Integrity Check Value (ICV) length is set to 96 bits. For transforms based on the "Magma" cipher 
(ENCR MAGMA MGM KTREE and ENCR MAGMA MGM MAC KTREE), the full ICV length is set to 
the block size (64 bits). 


4.6. Plaintext Padding 


The transforms defined in this document don't require any plaintext padding, as specified in 
[RFC9058]. This means that only those padding requirements that are imposed by the protocol are 
applied (4 bytes for ESP, no padding for IKEv2). 


4.7. AAD Construction 


4.7.1. ESP AAD 


Additional Authenticated Data (AAD) in ESP is constructed differently, depending on the 
transform being used and whether the Extended Sequence Number (ESN) is in use or not. The 
ENCR KUZNYECHIK MGM KTREE and ENCR MAGMA MGM KTREE transforms provide 
confidentiality, so the content of the ESP body is encrypted and the AAD consists of the ESP 
Security Parameter Index (SPI) and (E)SN. The AAD is constructed similarly to the AAD in 
[RFC4106]. 


On the other hand, the ENCR KUZNYECHIK MGM MAC KTREE and 

ENCR MAGMA MGM MAC KTREE transforms don't provide confidentiality; they provide only 
message authentication. For this purpose, the IV and the part of the ESP packet that is normally 
encrypted are included in the AAD. For these transforms, the encryption capability provided by 
MGM is not used. The AAD is constructed similarly to the AAD in [RFC4543]. 


1 2 & 

oK: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SPT | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 32-bit Sequence Number 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 4: AAD for AEAD Transforms with 32-Bit SN 
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1 2 3 

OUP 2 als s ra Ns ass rk 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SPI | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 64-bit Extended Sequence Number 

| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 5: AAD for AEAD Transforms with 64-Bit ESN 


1 2 3 
A SA 56m ð a rð 3 Pe i 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
SPI 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
32-bit Sequence Number 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
IV 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Payload Data (variable) 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Padding (0-255 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Pad Length | Next Header 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 6: AAD for Authentication-Only Transforms with 32-Bit SN 


+—+—4+— 2 —4+—-—4+—4—-4 
+ 


t+—+—4+—2—4—-—4+—4—-+4 


1 2 3 
Ok MZ SANS NORA SOROS E 5 NOVA SKO 5223144095 06728: OO 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
SPI 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
64-bit Extended Sequence Number 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
IV 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Payload Data (variable) 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Padding (0-255 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Pad Length | Next Header 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 7: AAD for Authentication-Only Transforms with 64-Bit ESN 


+— +— +—?— +t—— +t +— + 
+— +— +—?—+t—— +t +— + 
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4.7.2. IKEv2 AAD 


For IKEv2, the AAD consists of the IKEv2 Header, any unencrypted payloads following it (if 
present), and either the Encrypted payload header (Section 3.14 of [RFC7296]) or the Encrypted 
Fragment payload (Section 2.5 of [RFC7383]), depending on whether IKE fragmentation is used. 
The AAD is constructed similarly to the AAD in [RFC5282]. 


1 2 3 
01234567890123456789017Z7345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ IKEv2 Header ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ Unencrypted IKE Payloads ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Next Payload |C] RESERVED | Payload Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 8: AAD for IKEv2 in the Case of the Encrypted Payload 


1 2 3 
61234567896061234567395173414567696071 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ IKEv2 Header ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ Unencrypted IKE Payloads ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Next Payload |C] RESERVED | Payload Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Fragment Number | Total Fragments 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 9: AAD for IKEv2 in the Case of the Encrypted Fragment Payload 


4.8. Using Transforms 


When the SA is established, the i1, i2, and i3 parameters are set to 0 by the sender and a leaf key is 
calculated. The pnum parameter starts from 0 and is incremented with each message protected 
by the same leaf key. When the sender decides that the leaf should be changed, it increments the i3 
parameter and generates a new leaf key. The pnum parameter for the new leaf key is reset to 0, 
and the process continues. If the sender decides that a third-level key corresponding to i3 is used 
enough times, it increments i2, resets i3 to 0, and calculates a new leaf key. The pnum is reset to 0 
(as with every new leaf key), and the process continues. A similar procedure is used when a 
second-level key needs to be changed. 


A combination of i1, i2, i3, and pnum MUST NOT repeat for any particular SA. This means that the 
wrapping of these counters is not allowed: when i2, i3, or pnum reaches its respective maximum 
value, a procedure for changing a leaf key, described above, is executed, and if all four parameters 
reach their maximum values, the IPsec SA becomes unusable. 
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There may be other reasons to recalculate leaf keys besides reaching maximum values for the 
counters. For example, as described in Section 5, it is RECOMMENDED that the sender count the 
number of octets protected by a particular leaf key and generate a new key when some threshold 
is reached, and at the latest when reaching the octet limits stated in Section 5 for each of the 
ciphers. 


The receiver always uses i1, i2, and i3 from the received message. If they differ from the values in 
previously received packets, a new leaf key is calculated. The pnum parameter is always used 
from the received packet. To improve performance, implementations may cache recently used 
leaf keys. When a new leaf key is calculated (based on the values from the received message), the 
old key may be kept for some time to improve performance in the case of possible packet 
reordering (when packets protected by the old leaf key are delayed and arrive later). 


5. Security Considerations 


The most important security consideration for MGM is that the nonce MUST NOT repeat for a 
given key. For this reason, the transforms defined in this document MUST NOT be used with 
manual keying. 


Excessive use of the same key can give an attacker advantages in breaking security properties of 
the transforms defined in this document. For this reason, the amount of data that any particular 
key is used to protect should be limited. This is especially important for algorithms with a 64-bit 
block size (like "Magma", which currently are generally considered insecure after protecting a 
relatively small amount of data. For example, Section 3.4 of [SP800-67] limits the number of 


blocks that are allowed to be encrypted with the Triple DES cipher to 220 (8 MB of data). This 
document defines a rekeying mechanism that allows the mitigation of weak security of a 64-bit 
block cipher by frequently changing the encryption key. 


For transforms defined in this document, [GOST-ESP] recommends limiting the number of octets 
protected with a single K msg key by the following values: 


* 241 octets for transforms based on the "Kuznyechik" cipher 
(ENCR KUZNYECHIK MGM KTREE and ENCR KUZNYECHIK MGM MAC KTREE) 


* 228 octets for transforms based on the "Magma" cipher (ENCR MAGMA MGM KTREE and 
ENCR MAGMA MGM MAC KTREE) 


These values are based on combinatorial properties and may be further restricted if side-channel 
attacks are taken into consideration. Note that the limit for transforms based on the 
"Kuznyechik" cipher is unreachable because, due to the construction of the transforms, the 


number of protected messages is limited to 274 and each message (either IKEv2 messages or ESP 


datagrams) is limited to 218 octets in size, giving 240 octets as the maximum amount of data that 
can be protected with a single K msg. 
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Section 4 of [RFC9058] discusses the possibility of truncating authentication tags in MGM asa 
trade-off between message expansion and the probability of forgery. This specification truncates 
an authentication tag length for transforms based on the "Kuznyechik" cipher to 96 bits. This 
decreases message expansion while still providing a very low probability of forgery: 2n 

An attacker can send a lot of packets with arbitrarily chosen i1, i2, and i3 parameters. This will 1) 
force a recipient to recalculate the leaf key for every received packet if i1, i2, and i3 are different 
from these values in previously received packets, thus consuming CPU resources and 2) force a 
recipient to make verification attempts (that would fail) on a large amount of data, thus allowing 
the attacker a deeper analysis of the underlying cryptographic primitive (see [AEAD-USAGE- 
LIMITS]). Implementations MAY initiate rekeying if they deem that they receive too many packets 
with an invalid ICV. 


Security properties of MGM are discussed in [MGM-SECURITY]. 


6. IANA Considerations 


IANA maintains a registry called "Internet Key Exchange Version 2 (IKEv2) Parameters" with a 
subregistry called "Transform Type Values". IANA has added the following four Transform IDs to 
the "Transform Type 1 - Encryption Algorithm Transform IDs" subregistry. 


Number Name ESP Reference IKEv2 Reference 
32 ENCR KUZNYECHIK MGM KTREE RFC 9227 RFC 9227 

33 ENCR MAGMA MGM KTREE RFC 9227 RFC 9227 

34 ENCR KUZNYECHIK MGM MAC KTREE RFC 9227 Not allowed 

35 ENCR MAGMA MGM MAC KTREE RFC 9227 Not allowed 


Table 1: Transform IDs 
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Appendix A. Test Vectors 


In the following test vectors, binary data is represented in hexadecimal format. The numbers in 
square brackets indicate the size of the corresponding data in decimal format. 


1. ENCR KUZNYECHIK MGM KTREE (Example 1): 


Smyslov 
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transform 
b6 18 
e1 bc 
70 67 
Ko [32 
b6 18 
e1 be 
satt 25s 
7b 67 
il - 00, 
K msg [32] 
2: pd 
d8 80 
nonce [16] 
00 00 
IV [8]: 
00 00 
AAD [8]: 
51 46 
plaintext 
45 00 
0a 6f 
65 66 
5976 
ciphertext 
18 9d 
c6 d4 
62 97 
Bö 
ICV [1 
50 bð 
packet 
45 0 
0a 6f 
00 00 
9b ee 
60 05 
7b 9d 
ae 4d 


ESP 


ESP 


i2 = 


0 0 


key [44]: 


0c 14 
fa 73 
e6 f2 


0c 14 
fa 73 


e6 f2 


c9 0e 
bd 52 


00 00 
00 00 


53 6b 
[64]: 
00 3c 
0a 1d 
67 68 
77 61 


[64]: 


12 88 
ea fd 
b2 24 
e9 17 
23] 

70 a1 


70 
0a 1d 
00 00 
65 96 
aa 07 
eb 31 
a5 6f 


RTT] Le 
0 


5c 
79 
44 


SC 
79 


44 


0000, 


de 
Vic 


7b 
00 
00 


23 
08 
69 
62 


b7 
31 
bf 
9c 


5a 


00 
51 
18 
c6 
62 
85 
50 


35 
00 
6a 
63 


18 
64 
6d 
a9 


2b 


4d 
46 
9d 
d4 
97 
ff 
be 
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d9 


00 
53 
112 
ea 
b2 
e9 
70 


00 
6b 
88 
fd 
24 
17 
a1 


7f 
02 
6d 
66 


be 
90 
5f 
db 


86 


f 
00 
b7 
31 
bf 
9c 
5a 


95 


pnum = 


í 
3e 


f9 


01 
00 
6e 
67 


55 
lke 
d6 
af 


89 


32 
00 
18 
64 
6d 
a9 
2b 


ce a9 
Od 84 
2e 45 


ce a9 
Od 84 


2e 45 


b3 74 
56 9a 


7f 06 


ee cc 
58 00 
ef 70 
68 69 


4b 23 
Qc 3l 
f6 7e 
c2 3e 


f8 ed 


91 4f 
00 01 
f9 ea 
96 ef 
2b e3 
bf Øb 
d9 73 


2. ENCR KUZNYECHIK MGM KTREE (Example 2): 


Smyslov 


Informational 


2C 
b5 


ZC 
b5 


d7 
ab 


78 


0a 
61 
71 
01 


9b 
60 
7b 
ae 


0a 
00 
be 
90 
bif 
db 
86 


ac 
22 


ac 
22 


000000 


82 
2 


95 


6f 
62 
72 
02 


ee 
05 
9d 
Ad 


6f 
00 
55 
1c 
d6 
af 
89 


1b 
cc 


1b 
cc 


af 
1d 


2e 


5c 
38 


56 
38 


7b 
a4 


45 


c5 
64 
74 
04 


96 
07 
31 
6f 


EÐ 
00 
2:3 
Sil 
7e 
3e 
ed 


March 2022 


Page 15 


RFC 9227 


transform 


b6 18 Øc 
e1 bc fa 
7b 67 e6 


Ko [32 


b6 18 Øc 
e1 bc fa 


satt 25s 


i1 


7b 67 e6 


00, i2 = 


K_msg [32]: 


9a ba c6 
660 C2 f5 


nonce [16]: 


00 00 00 


IV [8]: 


AAD 


plaintext 


ciphertext [64]: 


ESP 


ESP 


00 00 01 
[8]: 
51 46 53 


45 00 00 
0a 6f 0a 
65 66 67 
59706099777 


78 0a 2c 
a4 fa 61 
15 4b 69 
tite 722956 
Icv [12]: 
C2 26 787 
packet [1 
45 00 00 
0a 6f 0a 
01 00 00 
f3 2d b4 
ac 1d fc 
62 81 12 
a4 d4 9a 


14 
73 
f2 


14 
ið 


12 


0001, 


57 
13 


00 
00 
6b 


[64]: 


3C 
1d 
68 
61 


62 
2f 
03 
ab 


40 


key [44]: 


5c 
79 
44 


SC 
79 


44 
78 
Od 
7b 
01 
00 
23 
08 
69 
62 
62 
66 
Ad 
fg 


83 


1124] Ë: 


70 
1d 
00 
do 
4b 
7c 
4d 


00 
51 
78 
a4 
1:5 
ff 
c2: 


48 
00 
6a 
63 


32 
C2 
c2: 
Øb 


8e 


5c 
46 
0a 
fa 
4b 
72: 
2f 
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3d 


00 
53 
2C 
61 
69 
56 
87 


fa 


00 
6b 
62 
2f 
03 
ab 
40 


7f 
02 
6d 
66 


fe 
d5 
20 
bb 


ce 


ff 
00 
62 
66 
4d 
fo 
83 


95 


pnum - 


f6 
7d 


f9 


01 
00 
6e 
67 


01 
e2 
90 
5e 


91 


32 
00 
32 
c2 
c2 
Øb 
8e 


3. ENCR_MAGMA_MGM_KTREE (Example 1): 


Smyslov 


ce a9 
Od 84 
2e 45 


ce a9 
Od 84 


2e 45 


1f b8 
53 0e 


7f 06 


ee b9 
67 00 
6f 70 
68 69 


76 32 
14 9b 
6d 59 
6c 


cc b8 


91 40 
00 10 
15 
bf 79 
1d ef 
a1 22 
3d fa 


Informational 


2C 
b5 


ZC 
b5 


d5 
6e 


78 


0a 
61 
71 
01 


f3 
ac 
62 
a4 


0a 
00 
fe 
d5 
20 
bb 
ce 


ac 
22 


ac 
22 


000000 


71 
7d 


95 


6f 
62 
72 
02 


2d 
1d 
81 
d4 


6f 
00 
01 
e2 
90 
5e 
91 


1b 
cc 


1b 
cc 


62 
48 


2e 


0a 
63 
73 
02 


b4 
US 
12 
9a 


0a 
01 
76 
14 
6d 
6c 
cc 


5c 
38 


56 
38 


36 
bc 


45 


c5 
64 
74 
04 


dð 
4b 
TO 
4d 


c5 
00 
32 
9b 
59 
7A 
b8 
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transform 


5b 
22 
Ch 
K P32] 
5b 


22 


50 
83 
36 


50 
83 


sad tll 


Chi 


il = 00, 


36 


key [36]: 
bf 33 78 
ef 58 9b 
63612 


bf 33 78 
ef 58 9b 


63 12 


i2 - 0000, 


K msg [32]: 


2:5 
5e 
nonce [ 
00 
IV [8]: 
00 
AAD [8] 
c8 


65 
9d 
8]: 
00 


00 


C2 


plaintext 


45 
0a 
65 
75 


00 
6f 
66 
76 


21 e2 70 
41 02 7d 


00 00 cf 
00 00 00 


b2 8d 00 
[64]: 

00 3c 24 
0a 1d 08 
67 68 69 
777216111562. 


ciphertext [64]: 
fa 08 40 33 2c 
d8 6f 8e 61 04 
f5 d2 42 69 49 
32 43 e2 3b a4 
ESP ICV [8]: 
5f 4a fa 8b 02 


ESP pac 


45 
0a 
00 
4a 
91 
99 
1:5 


ket 
0 


0 0 


6f 
ag 
91 
50 
ac 
52 


[108]: 

0 6c 00 
0a 1d c8 
00 00 fa 
7e 0c d8 
3f 4a f5 
ee 9e 32 
cc e8 5f 


87 
eb 


87 


2d 
00 
6a 
63 


Af 
03 
d3 
d1 


94 


62 
C2 
08 
6f 
d2 
43 
4a 
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of 


00 
b2 
40 
8e 
42 
e2 
fa 


38 
6a 


38 
6a 


f3 
89 


f3 
89 


0000, 


16 
19 


12 
00 
01 


00 
5b 
6c 
65 


c9 
64 
22 
84 


5c 


00 
8d 
33 
61 
69 
3b 
8b 


4d 
76 


7f 
02 
6d 
66 


64 
6b 
9e 
SC 


føl 
00 
2c 
04 
49 
a4 
02 


ca 
4a 


ca 
4a 


74 0f di 24 
a3 5d 5f 06 


74 0f d1 24 
a3 5d 5f 06 


pnum - 000000 


fc 
2b 


01 
00 
6e 
67 


4d 
b9 
1e 
91 


32 
00 
Af 
03 
d3 
d1 
94 


4. ENCR MAGMA MGM KTREE (Example 2): 


Smyslov 


26 e6 
TOES 


ed d4 
6d 00 
6f 70 
68 69 


S60 2 
df bd 
0e fc 
a7 19 


91 3e 
00 01 
3f c9 
87 64 
5a 22 
1e 84 
of 5c 


Informational 


bf 
01 


0a 
61 
71 
01 


4a 
91 
99 
15 


0a 
00 
64 
6b 
9e 
5c 


0c 
dc 


6f 
62 
72 
02 


91 
50 
ac 
52 


6f 
00 
4d 
b9 
1e 
91 


ba 
b2 


ba 
b2 


ca 
de 


0a 
63 
73 
02 


7e 
3f 
ee 
cc 


0a 
00 
8c 
df 
0e 
a7 


6c 
03 


6c 
03 


76 
7f 


c5 
64 
74 
04 


0c 
4a 
9e 
e8 


EÐ 
00 
ÞE 
bd 
FO 
19 
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transform 
5b 50 
22 83 
cf 36 
K P32] 
5b 50 
22 83 
salta]: 
cf 36 
il - 00, 
K msg [32] 
20 e0 
39 24 
nonce [8]: 
00 00 
IV [8]: 
00 00 
AAD [8]: 
c8 c2 
plaintext 
45 00 
0a 6f 
65 66 
5976 
ciphertext 


i2 - 


key [36]: 
bf 33 78 
ef 58 9b 
63212 


bf 33 78 
ef 58 9b 


63 12 
0001, 
46 d4 09 
Af 0e 29 


00 00 cf 
01 00 01 


b2 8d 00 
[64]: 

00 3c 24 

0a 1d 08 

67 68 69 

777611962. 
[64]: 


ESP 


ESP 


7a 71 48 
2:539 13 
1d c7 59 
4b 93 78 
ECV 815: 
dd 5d 50 
packet [1 
45 00 00 
0a 6f 0a 
01 00 00 
26 91 40 
9b 88 db 
d7 7a 07 
bf fe a1 


41 
5d 
f6 
bd 


9a 


fd 


08]: 


6c 
1d 
00 
a8 
AÐ 
1d 
dd 


87 
eb 


87 
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02 38 
f4 6a 


02 38 
f4 6a 


f3 
89 


f3 
89 


= 0001, 


9b 23 
1e 6f 


63 12 
00 00 
00 10 


00 00 
cf 5b 
6b 6c 
64 65 


b7 58 
Sua 
b3 ea 
OCR 


09 98 


00 00 
b2 8d 
48 41 
it 35d 
59 f6 
78 bd 
50 9a 


fo 
2e 


7f 
02 
6d 
66 


93 
e7 
b6 
ed 


isis 
00 
a5 
b9 
56 
08 
fd 


ca 74 0f d1 24 ba 
4a a3 5d 5f 06 


b2 


ca 74 0f d1 24 ba 
4a a3 5d 5f 06 


pnum - 


66 a5 0a 
5d 2e 13 


01 ed c1 
00 7c 00 
6e 6f 70 
67 68 69 


6a 8e ab 
6c 99 9c 
b1 4d 6b 
9a 01 91 


32591825 
00 00 10 
34 b7 58 
e4 37 1f 
b5 b3 ea 
97 6c 33 
b8 09 98 


7a 
55 


Qa 
61 
71 
01 


26 
9b 
d7 
bf 


0a 
00 
93 
e7 
b6 
ed 


5. ENCR KUZNYECHIK MGM MAC KTREE (Example 1): 


Smyslov 


Informational 


000000 


06 
f5 


6f 
62 
72 
02 


91 
88 
7a 
fe 


6f 
00 
6a 
6c 
b1 
9a 


b2 


5b 
da 


0a 
63 
73 
02 


40 
db 
07 
a1 


0a 
01 
8e 
99 
4d 
01 


6c 
03 


6c 
03 


4a 
08 


c5 
64 
74 
04 


a8 
72 
1d 
dd 


c5 
00 
ab 
9c 
6b 
91 
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transform 


98 
88 
6c 
K [32]: 
98 
88 
salten 
6c 


bd 
cc 
51 


bd 
cc 


Dale: 


51 


MERA 
K_msg [32]: 
98 f1 03 01 
8b ac b5 7e 
nonce [16]: 


00 
IV [8]: 
00 


00 


00 


AAD [80]: 


3d 
45 
0a 
65 
75 


plaintext 
ciphertext [0]: 


ESP ICV [12]: 


key [44]: 


34 
23 
cb 


34 
23 


cb 


12 


00 


00 


92 
00 
0a 
67 
77) 


ce 
92 
ac 


ce 
92 


ac 


0000, 


00 
00 


6a 
SC 
1d 
68 
61 


[0]: 


3b 
63 
93 


3b 
63 


93 
81 
00 
6c 


00 


ca c5 8c e5 e8 
ESP packet [112]: 


45 
0a 
00 
0a 
61 
7A 
01 


00 
6f 
00 
6f 
62 
7/92 
02 


00 
0a 
00 
0a 
63 
73 
02 


70 
1d 
00 
c5 
64 
74 
04 


00 
3d 
45 
0a 
65 
75 
ca 
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Ab 


00 
92 
00 
0a 
67 
Hil 
8c 


f3 


00 
6a 
SC 
1d 
68 
61 
e5 


2d 


USE 
00 
0c 
08 
69 
62 
e8 


e4 
9b 
62 


e4 
9b 


62 


87 cO 


06 


48 


64 3f e7 57 


79 1d 


87 c0 


06 


48 


64 3f e7 57 


79 1d 


pnum - 000000 


dd 
31 


c4 


6c 


32 
00 
Tól 
00 
6a 
63 
8b 


e1 bd 
e3 e4 


5b ea 


00 00 
05 11 
03 00 
6f 70 
68 69 


fo 4d 


91 9b 
00 01 
00 00 
48 5c 
6b 6c 
64 65 
4b f3 


85 
fg 


99 


00 
0a 
61 
71 
01 


0a 
00 
7f 
02 
6d 
66 
2d 


6. ENCR KUZNYECHIK MGM MAC KTREE (Example 2): 


Smyslov 


Informational 


a0 
a2 


62 


00 
6f 
62 
7/2 
02 


6f 
00 
01 
00 
6e 
67 
6c 


83 
b2 


83 
b2 


8f 
0c 


79 


00 
0a 
63 
WS 
02 


0a 
00 
05 
03 
6f 
68 
fo 


f4 
be 


f4 
be 


21 
8f 


1d 


00 
c5 
64 
74 
04 
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transform 


98 
88 
6c 
K [32]: 
98 
88 
salten 
6c 


bd 
cc 
51 


bd 
cc 


Dale: 


51 


3518-50 05 
K msg [32]: 
0254 87 
a8 a1 8c b2 
nonce [16]: 


00 
IV [8]: 
00 


00 


00 


AAD [80]: 


3d 
45 
0a 
65 
75 


plaintext 
ciphertext [0]: 


ESP ICV [12]: 


key [44]: 


34 
23 
cb 


34 
23 


cb 


12 


00 


00 


92 
00 
0a 
67 
77) 


ce 
92 
ac 


ce 
92 


ac 


0000, 


00 
00 


6a 
SC 
1d 
68 
61 


[0]: 


3b 
63 
93 


3b 
63 


93 
7c 
63 
6c 


01 


ba bc 67 ec 72 
ESP packet [112]: 


45 
0a 
01 
0a 
61 
7A 
01 


00 
6f 
00 
6f 
62 
7/2 
02 


00 
0a 
00 
0a 
63 
73 
02 


70 
1d 
00 
c5 
64 
74 
04 


00 
3d 
45 
0a 
65 
TAS 
ba 


a8 


06 
ac 
00 
6f 
66 
76 
bc 
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C3 


00 
92 
00 
0a 
67 
Vil 
67 


89 


USE 
00 
0c 
08 
69 
62 
y 


e4 
9b 
62 


e4 
9b 


62 


87 cO 
79 1d 


87 c0 


79 1d 


06 48 
64 3f e7 57 


06 48 
64 3f e7 57 


pnum - 000000 


35 
81 


c4 


b4 


32 
00 
fb 
00 
6a 
63 
a8 


91 9a 
411152 


5b ea 


00 00 
05 07 
08 00 
6f 70 
68 69 


Be 91 


91 96 
00 06 
00 00 
43 5c 
6b 6c 
64 65 
c3 1a 


7. ENCR MAGMA MGM MAC KTREE (Example 1): 


Smyslov 


Informational 


75 
91 


99 


01 
0a 
61 
71 
01 


0a 
00 
7f 
02 
6d 
66 
89 


13 
01 


62 


00 
6f 
62 
7/2 
02 


6f 
00 
01 
00 
6e 
67 
b4 


83 
b2 


83 
b2 


b6 
67 


79 


00 
0a 
63 
WS 
02 


0a 
00 
05 
08 
6f 
68 
0e 


f4 
be 


f4 
be 


f8 
84 


1d 


00 
c5 
64 
74 
04 
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transform key [36] 
dO 65 b5 30 fa 
2c 1c 07 6d fa 
88 79 8f 29 

Kars 2 
dO 65 b5 30 fa 
2c 1c 07 6d fa 

sad tms 
88 79 8f 29 

E= oR 0000, 

K msg [32]: 
4c 61 45 99 að 
ea f2 3e da f8 

nonce [8]: 

00 00 00 00 88 

IV [8] 

00 00 00 00 00 

AAD [80]: 
3e 40 69 9c 00 
45 00 00 3c ðe 
0a 6f 0a 1d 08 
65 66 67 68 69 
576162 

plaintext [0]: 

ciphertext [0]: 

ESP ICV [8]: 


4d d4 25 8a 25 
ESP packet [108]: 


45 
0a 
00 
0a 
61 
7A 
01 


00 
6f 
00 
6f 
62 
7/92 
02 


00 
0a 
00 
0a 
63 
73 
02 


6c 
1d 
00 
c5 
64 
74 
04 


00 
3e 
45 
0a 
65 
75 
4d 


7e 


13 
40 
00 
6f 
66 
76 
d4 
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95 


00 
69 
00 
0a 
67 
Veil 
25 


df 


00 
9c 
SC 
1d 
68 
61 
8a 


00 
7f 
02 
6d 
66 


USE 
00 
0e 
08 
69 
62 
25 


57 
4a 


57 
4a 


Øc 1d 86 2a 
07 a8 85 7d 


Øc 1d 86 2a 
07 a8 85 7d 


pnum = 000000 


87 
86 


00 
01 
00 
6e 
67 


32 
00 
08 
00 
6a 
63 
35 


24 0a 
1c 68 


00 00 
03 fa 
15 00 
6f 70 
68 69 


91 8d 
00 01 
00 00 
36) 25¢ 
6b 6c 
64 65 
95 df 


8. ENCR MAGMA MGM MAC KTREE (Example 2): 


Smyslov 


Informational 


e1 
3b 


00 
0a 
61 
71 
01 


0a 
00 
7f 
02 
6d 
66 


00 
a4 


00 
6f 
62 
7/2 
02 


6f 
00 
01 
00 
6e 
67 


e3 
bd 


e3 
bd 


e1 
04 


00 
0a 
63 
WS 
02 


0a 
00 
03 
15 
6f 
68 


39 
30 


39 
30 


b7 
46 


00 
c5 
64 
74 
04 


EÐ 
00 
fa 
00 
70 
69 
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transform key [36] 
dO 65 b5 30 fa 
2c 1c 07 6d fa 

88 79 8f 29 
K [32]: 

dO 65 b5 30 fa 

2c 1c 07 6d fa 
salt [4]: 

88 79 8f 29 
3515-500 798651:2. 0000, 
K msg [32]: 

b4 f3 f9 0d c4 

e4 36 32 b6 79 
nonce [8]: 

00 00 00 00 88 
IV [8] 

00 00 00 00 01 
AAD [80]: 

3e 40 69 9c 00 

45 00 00 3c ðe 

0a 6f Ba 1d 08 

65 66 67 68 69 

TESS TKS. TEE en) (OP 
plaintext [0]: 
ciphertext [0]: 
ESP ICV [8]: 


84 84 a9 23 30 
ESP packet [108]: 


45 
0a 
01 
0a 
61 
Tal 
01 


00 
6f 
00 
6f 
62 
72 
02 


00 
0a 
00 
0a 
63 
73 
02 


6c 
1d 
00 
C5 
64 
74 
04 


00 
3e 
45 
0a 
65 
75 
84 
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00 


00 
6a 


a0 


18 
40 
00 
6f 
66 
76 
84 
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00 06 00 
00 00 7f 
31856 602 
6b 6c 6d 
64 65 66 


00 00 ff 
69 9c 00 
00 3c 0e 
0a 1d 08 
67 68 69 
77 61 62 
a9 23 30 


57 
4a 


57 
4a 


Øc 1d 86 2a 
07 a8 85 7d 


Øc 1d 86 2a 
07 a8 85 7d 


pnum - 000000 


af 
96 


00 
01 
00 
6e 
67 


32 
00 
13 
00 
6a 
63 
a0 


dO eb 
09 ea 


00 00 
03 ef 
1a 00 
6f 70 
68 69 


91 88 
00 06 
00 00 
SRC 
6b 6c 
64 65 
b1 96 


45 
fg 


01 
0a 
61 
71 
01 


0a 
00 
7f 
02 
6d 
66 


49 
b8 


00 
6f 
62 
72 
02 


6f 
00 
01 
00 
6e 
67 


e3 
bd 


e3 
bd 


f2 
e2 


00 
0a 
63 
#3 
02 


0a 
00 
03 
1a 
6f 
68 


39 
30 


39 
30 


fg 
28 


00 
c5 
64 
74 
04 


EÐ 
00 
ef 
00 
70 
69 
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